x86/xstate: Use a guests CPUID policy, rather than allowing all features
authorAndrew Cooper <andrew.cooper3@citrix.com>
Mon, 30 Jul 2018 09:27:33 +0000 (11:27 +0200)
committerJan Beulich <jbeulich@suse.com>
Mon, 30 Jul 2018 09:27:33 +0000 (11:27 +0200)
commit543027c9842d8416047ef38846d2de1295052e92
tree0d91f0d03c35f194fb35d571a5f5ef487796dfd2
parent037fe82cf5fadf0f74c3da70560ee7592a8f2083
x86/xstate: Use a guests CPUID policy, rather than allowing all features

It turns out that Xen has never enforced that a domain remain within the
xstate features advertised in CPUID.

The check of new_bv against xfeature_mask ensures that a domain stays within
the set of features that Xen has enabled in hardware (and therefore isn't a
security problem), but this does means that attempts to level a guest for
migration safety might not be effective if the guest ignores CPUID.

Check the CPUID policy in validate_xstate() (for incoming migration) and in
handle_xsetbv() (for guest XSETBV instructions).  This subsumes the PKRU check
for PV guests in handle_xsetbv() (and also demonstrates that I should have
spotted this problem while reviewing c/s fbf9971241f).

For migration, this is correct despite the current (mis)ordering of data
because d->arch.cpuid is the applicable max policy.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 361b835fa00d9f45167c50a60e054ccf22c065d7
master date: 2018-07-19 19:57:26 +0100
xen/arch/x86/domctl.c
xen/arch/x86/hvm/hvm.c
xen/arch/x86/xstate.c
xen/include/asm-x86/xstate.h